github actions
Github上でデプロイコマンドやらビルドコマンドを実行できる状態にしておきたいのでやる。
まずは軽い勉強から始めましょう。公式DocとPocで理解を深めていきます。
1. 「クイックスタート」と「概要」でまずは大枠掴める
ワークフローが自動プロセスの1塊になる。
その中に1つ以上のjobとワークフロ実行トリガーのeventを定義しておく。
トリガーとなるeventは複数の種類と設定があるので、お好みのものがあれば使うように。
jobが、1ワークフロー内における実行単位となる。ワークフローには複数のjobを持てる。
jobの中で色んなスクリプトやらactionやらを実行することになる。
また、jobは1つのrunner上で動作するため、job定義の際にはrunnnerの種類やスペックも指定してあげると良い。
runnerっていうのは、jobが実行するためのGithubが持つ仮想サーバー。色んなスペックが用意されてるっぽい。
actionてのは、jobの中で実行するスクリプトの1つとして実行できるもの。
他の誰か、もしくは自分が、ある一連処理などをパッケージ化して1つのアクションに収めてる。
それを自分たちが使うって感じ。
色んな人が作ってるので、種類はいっぱいあると思う。
いうなればライブラリ的な立ち位置かな、いや、ツール的な立ち位置かな。
例：
Input
hr.icon
大体覚えておいたら良さげなのは...
code: sample.yml
name: ... # <- ワークフローの名前。githubのコンソールで見分けがつく
on: # <- ワークフローを実行するトリガー。色々ある
jobs: # ちょっとわからん。あとで理解深める...
Github Actionsを語る上で覚えておきたいメンバーてのがあるっぽいよ
ワークフロー
ワークフローは、1 つ以上のジョブを実行する構成可能な自動プロセスです。ワークフローは、リポジトリにチェックインされた YAML ファイルによって定義され、リポジトリ内のイベントによってトリガーされたときに実行されます。また、手動でトリガーしたり、定義されたスケジュールでトリガーしたりすることもできます。
.github/workflowsの配下に定義するファイルがワークフロー。
ここで何やら設定や実行内容やらを指定する感じだな。
イベント
ワークフロー実行のトリガー。それだけ。
指定ワークフローが実行されるタイミングを制御。
Job
ジョブは、同じランナー上で実行されるワークフロー内の一連のステップです。各ステップは、実行されるシェル スクリプト、または実行されるアクションのいずれかです。ステップは順番に実行され、相互に依存します。各ステップは同じランナー上で実行されるため、あるステップ間でデータを共有できます。たとえば、アプリケーションをビルドするステップの後に、ビルドされたアプリケーションをテストするステップを置くことができます。
ジョブの他のジョブとの依存関係を構成できます。デフォルトでは、ジョブには依存関係がなく、相互に並行して実行されます。ジョブが別のジョブに依存関係を持つ場合、そのジョブは、依存関係にあるジョブが完了するまで待機してから実行されます。
ワークフローにて実行される一連のステップの集まり。
ちなみに、ワークフローは複数のJobを持てるらしい。
作業に依存関係がないものを別Jobとして扱うのかな。並行実行したい時とか。そんな感じだろうな。
q.icon Runnerはジョブに1つ与えられるみたいな感じだろうか
a.icon yes
Action
アクションは、複雑だが頻繁に繰り返されるタスクを実行する GitHub Actions プラットフォームのカスタム アプリケーションです。アクションを使用すると、ワークフロー ファイルに記述する繰り返しコードの量を減らすことができます。
q.icon Jobを自分で定義する必要がないとかかな。JobというよりなかのStepかな？
a.icon yes
Runner
ランナーは、ワークフローがトリガーされたときにそれを実行するサーバーです。各ランナーは一度に 1 つのジョブを実行できます。GitHub は、ワークフローを実行するための Ubuntu Linux、Microsoft Windows、および macOS ランナーを提供します。各ワークフローの実行は、新しくプロビジョニングされた新しい仮想マシンで実行されます。GitHub では、より大規模な構成で利用できる、より大きなランナーも提供しています。
はい。やはり1ジョブにつき1ランナーか。
LinuxはUbuntuだけかな。